Патерн Saga: Реалізація розподілених транзакцій для мікросервісів

У світі мікросервісів підтримка узгодженості даних між кількома сервісами може бути значним викликом. Традиційні ACID-транзакції (атомарність, узгодженість, ізольованість, довговічність), які зазвичай використовуються в монолітних додатках, часто не підходять для розподілених середовищ. Саме тут на допомогу приходить патерн Saga, що забезпечує надійне рішення для управління розподіленими транзакціями та гарантує цілісність даних у мікросервісах.

Що таке патерн Saga?

Патерн Saga — це шаблон проєктування, який використовується для управління послідовністю локальних транзакцій у кількох мікросервісах. Він надає спосіб досягнення кінцевої узгодженості, що означає, що хоча дані можуть бути тимчасово неузгодженими, зрештою вони досягнуть узгодженого стану. Замість того, щоб покладатися на одну атомарну транзакцію, що охоплює кілька сервісів, патерн Saga розбиває транзакцію на серію менших, незалежних транзакцій, кожна з яких виконується одним сервісом.

Кожна локальна транзакція в межах Saga оновлює базу даних одного мікросервісу. Якщо одна з транзакцій зазнає невдачі, Saga виконує серію компенсуючих транзакцій, щоб скасувати зміни, зроблені попередніми транзакціями, фактично відкочуючи всю операцію.

Навіщо використовувати патерн Saga?

Кілька факторів роблять патерн Saga цінним інструментом для управління транзакціями в мікросервісних архітектурах:

• Слабка зв'язаність: Saga сприяє слабкій зв'язаності між мікросервісами, дозволяючи їм розвиватися незалежно, не впливаючи на інші сервіси. Це ключова перевага мікросервісних архітектур.
• Масштабованість: Уникаючи довготривалих розподілених транзакцій, Saga покращує масштабованість та продуктивність. Кожен мікросервіс може обробляти свої власні транзакції незалежно, зменшуючи конкуренцію та підвищуючи пропускну здатність.
• Стійкість до відмов: Saga розроблена для стійкості до збоїв. Якщо транзакція зазнає невдачі, Saga може бути відкочена, запобігаючи неузгодженості даних і забезпечуючи, що система залишається в узгодженому стані.
• Гнучкість: Патерн Saga забезпечує гнучкість в управлінні складними бізнес-процесами, що охоплюють кілька сервісів. Він дозволяє визначати послідовність транзакцій та компенсуючі дії, які слід виконати у випадку збою.

ACID проти BASE

Розуміння різниці між ACID (Atomicity, Consistency, Isolation, Durability) та BASE (Basically Available, Soft state, Eventually consistent) є вирішальним при виборі, чи використовувати патерн Saga.

• ACID (Атомарність, Узгодженість, Ізольованість, Довговічність): Гарантує надійну обробку транзакцій. Атомарність забезпечує, що або всі операції в межах транзакції виконуються успішно, або жодна з них. Узгодженість гарантує, що транзакція переводить базу даних з одного дійсного стану в інший. Ізольованість забезпечує, що паралельні транзакції не заважають одна одній. Довговічність гарантує, що після фіксації транзакції вона залишається такою навіть у разі збою системи.
• BASE (Basically Available, Soft state, Eventually consistent): Це інший підхід, розроблений для розподілених систем. Basically Available (Переважно доступна) означає, що система доступна більшу частину часу. Soft state (М'який стан) означає, що стан системи може змінюватися з часом, навіть без введення даних. Eventually consistent (Кінцева узгодженість) означає, що система врешті-решт стане узгодженою, коли перестане отримувати вхідні дані. Патерн Saga відповідає принципам BASE.

Дві основні стратегії реалізації Saga

Існує два основні способи реалізації патерну Saga: хореографія та оркестрація.

1. Saga на основі хореографії

У Saga на основі хореографії кожен мікросервіс бере участь у Saga, прослуховуючи події, опубліковані іншими мікросервісами, і реагуючи відповідним чином. Немає центрального оркестратора; кожен сервіс знає свої обов'язки та коли виконувати свої дії.

Як це працює:

1. Saga починається, коли мікросервіс публікує подію, що вказує на початок транзакції.
2. Інші мікросервіси підписуються на цю подію і, отримавши її, виконують свою локальну транзакцію.
3. Після завершення своєї транзакції кожен мікросервіс публікує іншу подію, що вказує на успіх або невдачу своєї операції.
4. Інші мікросервіси прослуховують ці події та вживають відповідних заходів, або переходячи до наступного кроку в Saga, або ініціюючи компенсуючі транзакції, якщо виникає помилка.

Приклад: Розміщення замовлення в електронній комерції (Хореографія)

1. Сервіс замовлень: Отримує новий запит на замовлення та публікує подію `OrderCreated`.
2. Сервіс інвентаризації: Підписується на `OrderCreated`. Отримавши подію, він перевіряє наявність товару. Якщо достатньо, він резервує товари та публікує `InventoryReserved`. Якщо недостатньо, він публікує `InventoryReservationFailed`.
3. Платіжний сервіс: Підписується на `InventoryReserved`. Отримавши подію, він обробляє платіж. Якщо успішно, він публікує `PaymentProcessed`. Якщо невдало, він публікує `PaymentFailed`.
4. Сервіс доставки: Підписується на `PaymentProcessed`. Отримавши подію, він готує відправлення та публікує `ShipmentPrepared`.
5. Сервіс замовлень: Підписується на `ShipmentPrepared`. Отримавши подію, він позначає замовлення як виконане.
6. Компенсація: Якщо публікується `PaymentFailed` або `InventoryReservationFailed`, інші сервіси прослуховують це і виконують компенсуючі транзакції (наприклад, звільняють зарезервований товар).

Плюси хореографії:

• Простота: Легше реалізувати для простих робочих процесів.
• Децентралізація: Сприяє слабкій зв'язаності та незалежному розвитку мікросервісів.

Мінуси хореографії:

• Складність: Може стати складною в управлінні зі збільшенням кількості учасників Saga.
• Прозорість: Важко відстежувати загальний прогрес і стан Saga.
• Зв'язаність: Хоча й сприяє слабкій зв'язаності, сервіси все одно повинні знати про події, опубліковані іншими сервісами.

2. Saga на основі оркестрації

У Saga на основі оркестрації центральний оркестратор (часто реалізований як окремий сервіс або скінченний автомат) керує Saga та координує виконання локальних транзакцій мікросервісами-учасниками. Оркестратор вказує кожному сервісу, що і коли робити.

Як це працює:

1. Saga починається, коли клієнт надсилає запит оркестратору на ініціювання транзакції.
2. Оркестратор надсилає команди мікросервісам-учасникам для виконання їхніх локальних транзакцій.
3. Кожен мікросервіс виконує свою транзакцію та повідомляє оркестратора про успіх або невдачу.
4. На основі результату оркестратор вирішує, чи переходити до наступного кроку, чи ініціювати компенсуючі транзакції.

Приклад: Розміщення замовлення в електронній комерції (Оркестрація)

1. Оркестратор замовлень: Отримує новий запит на замовлення.
2. Оркестратор замовлень: Надсилає команду до Сервісу інвентаризації для резервування товарів.
3. Сервіс інвентаризації: Резервує товари та повідомляє Оркестратора замовлень.
4. Оркестратор замовлень: Надсилає команду до Платіжного сервісу для обробки платежу.
5. Платіжний сервіс: Обробляє платіж та повідомляє Оркестратора замовлень.
6. Оркестратор замовлень: Надсилає команду до Сервісу доставки для підготовки відправлення.
7. Сервіс доставки: Готує відправлення та повідомляє Оркестратора замовлень.
8. Оркестратор замовлень: Позначає замовлення як виконане.
9. Компенсація: Якщо будь-який крок зазнає невдачі, Оркестратор замовлень надсилає компенсуючі команди відповідним сервісам (наприклад, звільнення зарезервованого товару).

Плюси оркестрації:

• Централізований контроль: Легше керувати та моніторити Saga з центральної точки.
• Покращена прозорість: Оркестратор забезпечує чітке уявлення про загальний прогрес і стан Saga.
• Зменшена зв'язаність: Мікросервіси повинні спілкуватися лише з оркестратором, що зменшує прямі залежності між ними.

Мінуси оркестрації:

• Складність: Може бути складнішою в початковій реалізації, особливо для простих робочих процесів.
• Єдина точка відмови: Оркестратор може стати єдиною точкою відмови, хоча це можна пом'якшити за допомогою резервування та заходів відмовостійкості.

Реалізація компенсуючих транзакцій

Важливим аспектом патерну Saga є реалізація компенсуючих транзакцій. Ці транзакції виконуються для скасування ефектів раніше завершених транзакцій у разі збою. Мета полягає в тому, щоб повернути систему в узгоджений стан, навіть якщо загальну Saga неможливо завершити.

Ключові аспекти компенсуючих транзакцій:

• Ідемпотентність: Компенсуючі транзакції повинні бути ідемпотентними, тобто їх можна виконувати кілька разів без зміни результату. Це важливо, оскільки збої можуть статися в будь-який момент, і компенсуюча транзакція може бути повторена.
• Обробка збоїв: Компенсуючі транзакції також можуть зазнати невдачі. Вам потрібно мати стратегію обробки збоїв у компенсуючих транзакціях, таку як повторення спроб, логування помилок та сповіщення адміністраторів.
• Узгодженість даних: Компенсуючі транзакції повинні забезпечувати узгодженість даних. Це може включати відновлення даних до попереднього стану, видалення новостворених даних або оновлення даних, щоб відобразити скасування транзакції.

Приклади компенсуючих транзакцій:

• Сервіс інвентаризації: Якщо Сервіс інвентаризації зарезервував товари, але платіж не вдався, компенсуючою транзакцією буде звільнення зарезервованих товарів.
• Платіжний сервіс: Якщо Платіжний сервіс обробив платіж, але доставка не вдалася, компенсуюча транзакція може включати повернення коштів.

Виклики та міркування

Хоча патерн Saga пропонує значні переваги, він також створює певні виклики та міркування:

• Складність: Реалізація патерну Saga може бути складною, особливо для заплутаних бізнес-процесів. Необхідне ретельне планування та проєктування.
• Кінцева узгодженість: Патерн Saga забезпечує кінцеву узгодженість, що означає, що дані можуть бути тимчасово неузгодженими. Це може бути проблемою для додатків, які вимагають сильних гарантій узгодженості.
• Тестування: Тестування Saga може бути складним через їх розподілений характер та потенціал для збоїв у різних точках.
• Моніторинг: Моніторинг прогресу та стану Saga є вирішальним для виявлення та вирішення проблем. Вам потрібно мати відповідні інструменти та процеси моніторингу.
• Ідемпотентність: Забезпечення ідемпотентності транзакцій та компенсуючих транзакцій є вирішальним для запобігання неузгодженості даних.
• Ізоляція: Оскільки Saga включає кілька локальних транзакцій, ізоляція може бути проблемою. Можуть знадобитися такі стратегії, як семантичні блокування або оптимістичне блокування.

Сценарії використання та приклади

Патерн Saga добре підходить для різноманітних сценаріїв використання, особливо в розподілених системах та мікросервісних архітектурах. Ось кілька поширених прикладів:

• Управління замовленнями в електронній комерції: Як показано в наведених вище прикладах, патерн Saga можна використовувати для управління всім життєвим циклом замовлення, від його створення до обробки платежу та доставки.
• Фінансові транзакції: Патерн Saga можна використовувати для управління складними фінансовими транзакціями, що включають кілька систем, таких як переказ коштів, заявки на кредити та страхові вимоги.
• Управління ланцюгом постачання: Патерн Saga можна використовувати для координації діяльності між кількома суб'єктами в ланцюгу постачання, такими як виробники, дистриб'ютори та роздрібні торговці.
• Системи охорони здоров'я: Патерн Saga можна використовувати для управління медичними записами пацієнтів та координації догляду між різними відділеннями та постачальниками послуг.

Приклад: Глобальна банківська транзакція

Уявіть собі сценарій глобальної банківської транзакції між двома різними банками, розташованими в різних країнах, що підпадають під дію різних нормативних актів та перевірок відповідності. Патерн Saga може забезпечити, щоб транзакція виконувалася за визначеними кроками:

1. Ініціація транзакції: Клієнт ініціює переказ коштів зі свого рахунку в Банку А (розташованому в США) на рахунок одержувача в Банку Б (розташованому в Німеччині).
2. Банк А - Перевірка рахунку: Банк А перевіряє рахунок клієнта, наявність достатніх коштів та відсутність блокувань чи обмежень.
3. Перевірка відповідності (Банк А): Банк А проводить перевірку відповідності, щоб переконатися, що транзакція не порушує правил боротьби з відмиванням грошей (AML) або будь-яких міжнародних санкцій.
4. Переказ коштів (Банк А): Банк А списує кошти з рахунку клієнта та надсилає їх до клірингового центру або банку-посередника.
5. Обробка в кліринговому центрі: Кліринговий центр обробляє транзакцію, виконує конвертацію валют (USD в EUR) та направляє кошти до Банку Б.
6. Банк Б - Перевірка рахунку: Банк Б перевіряє рахунок одержувача та переконується, що він активний і може приймати кошти.
7. Перевірка відповідності (Банк Б): Банк Б проводить власну перевірку відповідності, дотримуючись німецьких та європейських нормативів.
8. Зарахування на рахунок (Банк Б): Банк Б зараховує кошти на рахунок одержувача.
9. Підтвердження: Банк Б надсилає повідомлення про підтвердження до Банку А, який потім повідомляє клієнта про завершення транзакції.

Компенсуючі транзакції:

• Якщо перевірка відповідності в Банку А не проходить, транзакція скасовується, і кошти з рахунку клієнта не списуються.
• Якщо перевірка відповідності в Банку Б не проходить, кошти повертаються до Банку А, і рахунок клієнта поповнюється назад.
• Якщо виникають проблеми з конвертацією валют або маршрутизацією в кліринговому центрі, транзакція скасовується, і кошти повертаються до Банку А.

Інструменти та технології

Кілька інструментів та технологій можуть допомогти в реалізації патерну Saga:

• Черги повідомлень: Apache Kafka, RabbitMQ та Amazon SQS можна використовувати для публікації та підписки на події в Saga на основі хореографії.
• Рушії робочих процесів: Camunda, Zeebe та Apache Airflow можна використовувати для реалізації оркестраторів та управління складними робочими процесами.
• Event Sourcing: Event sourcing (джерело подій) можна використовувати для відстеження історії подій у Saga та полегшення відкату в разі збою.
• Менеджери розподілених транзакцій: Деякі менеджери розподілених транзакцій, такі як Atomikos, можна використовувати для координації транзакцій між кількома сервісами. Однак вони можуть не підходити для всіх мікросервісних архітектур через свої внутрішні обмеження в розподілених середовищах.
• Фреймворки Saga: Існують також фреймворки Saga, які надають абстракції та інструменти для реалізації патерну Saga.

Найкращі практики для реалізації патерну Saga

Щоб ефективно реалізувати патерн Saga, враховуйте наступні найкращі практики:

• Ретельне проєктування: Ретельно проаналізуйте ваші бізнес-вимоги та спроєктуйте Saga відповідним чином. Визначте мікросервіси-учасники, послідовність транзакцій та компенсуючі дії.
• Ідемпотентність: Переконайтеся, що всі транзакції та компенсуючі транзакції є ідемпотентними.
• Обробка помилок: Впровадьте надійні механізми обробки помилок для боротьби зі збоями в будь-якій точці Saga.
• Моніторинг та логування: Впровадьте комплексний моніторинг та логування для відстеження прогресу та стану Saga.
• Тестування: Ретельно тестуйте ваші Saga, щоб переконатися, що вони функціонують правильно та коректно обробляють збої.
• Семантичні блокування: Впроваджуйте семантичні блокування для запобігання одночасним оновленням одних і тих же даних різними Saga.
• Оптимістичне блокування: Використовуйте оптимістичне блокування для виявлення та запобігання конфліктам між паралельними транзакціями.
• Вибір правильної стратегії реалізації: Ретельно зважте компроміси між хореографією та оркестрацією та оберіть стратегію, яка найкраще відповідає вашим потребам.
• Визначення чітких політик компенсації: Встановіть чіткі політики для обробки компенсації, включаючи умови, за яких спрацьовує компенсація, та конкретні дії, які необхідно виконати.

Висновок

Патерн Saga — це потужний інструмент для управління розподіленими транзакціями в мікросервісних архітектурах. Розбиваючи транзакції на серію менших, незалежних транзакцій та надаючи механізм для компенсації збоїв, патерн Saga дозволяє підтримувати узгодженість даних та створювати стійкі, масштабовані та слабо зв'язані системи. Хоча реалізація патерну Saga може бути складною, переваги, які він пропонує з точки зору гнучкості, масштабованості та стійкості, роблять його цінним активом для будь-якої мікросервісної архітектури.

Розуміння нюансів патерну Saga, компромісів між хореографією та оркестрацією, а також важливості компенсуючих транзакцій дозволить вам проєктувати та впроваджувати надійні розподілені системи, що відповідають вимогам сучасних складних бізнес-середовищ. Використання патерну Saga — це крок до створення справді стійких та масштабованих мікросервісних архітектур, здатних впевнено обробляти навіть найскладніші розподілені транзакції. Не забувайте враховувати ваші конкретні потреби та контекст при застосуванні цього патерну, і постійно вдосконалюйте свою реалізацію на основі реального досвіду та відгуків.